❌ Failed checks (1 warning)

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

• X
• Mastodon
• Reddit
• LinkedIn

• Upgrade Next.js to v16.2 and React to v19.2 with React Compiler enabled
• Add context caching utility for Gemini 3.1 Pro to reduce token usage
• Integrate custom tools endpoint for improved agent tool-calling reliability
• Enhance system prompts with advanced reasoning approach for geospatial analysis
• Update configuration for Next.js 16 standards (turbopack, cacheComponents, proxy)

New context caching utility for token optimization

lib/utils/context-cache.ts

Add custom tools endpoint support to getModel

lib/utils/index.ts

Rename middleware to proxy for Next.js 16

proxy.ts

Description

proxy.ts exports proxy() instead of exporting middleware() from a middleware.ts entrypoint,
so Next.js will not execute this code as middleware. Any request-handling logic in this file
(server-action bypass, redirects, future auth) becomes a no-op at runtime.

Code

proxy.ts[4]

+export function proxy(request: NextRequest) {

Evidence

The PR changes the exported handler to proxy() in proxy.ts; there is no middleware.ts
entrypoint in the repo, and proxy.ts is not referenced elsewhere, so the middleware behavior is
effectively removed.

proxy.ts[1-24]
Best Practice: Next.js Middleware conventions

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`proxy.ts` will not be executed as Next.js middleware. Next.js middleware must live in `middleware.ts` (or `middleware.js`) and export a function named `middleware` (or a default export).

## Issue Context
This PR appears to have renamed middleware to align with a perceived Next.js 16 change, but Next.js still uses the `middleware.*` convention. As a result, the redirect/auth logic is silently disabled.

## Fix Focus Areas
- proxy.ts[1-24]

## Suggested fix
- Rename `proxy.ts` back to `middleware.ts`.
- Rename `export function proxy` back to `export function middleware` (or `export default function middleware`).
- If you want to keep a `proxy.ts` helper, keep the logic there but re-export it from `middleware.ts`:
 - `import { proxy } from './proxy'`
 - `export function middleware(req) { return proxy(req) }`
- Ensure the `config.matcher` remains exported from the middleware entrypoint.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

eslint-config-next is upgraded to 16.x while eslint remains on 8.x, but the resolved
eslint-config-next@16.2.5 declares a peer dependency of eslint >=9.0.0. This can cause
dependency resolution failures or forced peer overrides depending on your npm/CI settings.

Code

package.json[R112-116]

+    "babel-plugin-react-compiler": "^1.0.0",
    "cross-env": "^7.0.3",
    "eslint": "^8.57.1",
-    "eslint-config-next": "^14.2.28",
+    "eslint-config-next": "^16.x",
    "postcss": "^8.5.3",

Evidence

package.json keeps eslint at v8 while moving eslint-config-next to a v16 range. The checked-in
lockfile resolves eslint-config-next to 16.2.5 and shows it requires eslint >=9, creating a peer
dependency conflict.

package.json[112-118]
package-lock.json[11713-11733]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`eslint-config-next@16.x` requires `eslint >=9`, but the repo is pinned to `eslint ^8.57.1`. This may break installs (ERESOLVE) or require disabling peer checks.

## Issue Context
The lockfile already resolves `eslint-config-next` to 16.2.5 and declares the peer requirement, so the mismatch is present in the committed dependency set.

## Fix Focus Areas
- package.json[112-118]
- package-lock.json[11713-11733]

## Suggested fix
Choose one:
1) Upgrade eslint to a compatible major:
- Set `"eslint": "^9.x"` (and adjust any lint config changes needed).

2) Keep eslint v8:
- Downgrade/pin `eslint-config-next` to a version that supports eslint v8.

Then regenerate `package-lock.json` to reflect the consistent set.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The new context cache is keyed by ${conversationId}:${messageCount}, but
cacheConversationContext() always stores under the current messages.length, so subsequent turns
(different messageCount) will almost always miss and provide no benefit. Additionally,
clearConversationCache() uses startsWith(conversationId), which can delete caches for other
conversations with IDs sharing the same prefix.

Code

lib/utils/context-cache.ts[R24-96]

+function generateCacheKey(conversationId: string, messageCount: number): string {
+  return `${conversationId}:${messageCount}`;
+}
+
+/**
+ * Cache conversation context to reduce token usage
+ */
+export function cacheConversationContext(
+  conversationId: string,
+  messages: CoreMessage[],
+  systemPrompt: string
+): void {
+  const messageCheckpoint = messages.length;
+  const cacheKey = generateCacheKey(conversationId, messageCheckpoint);
+
+  // Create a serialized prefix of the conversation
+  const cachedPrefix = messages
+    .slice(0, Math.floor(messages.length * 0.8)) // Cache first 80% of messages
+    .map(m => `${m.role}: ${typeof m.content === 'string' ? m.content : '[complex content]'}`)
+    .join('\n');
+
+  const cachedContext: CachedContext = {
+    conversationId,
+    messageCheckpoint,
+    cachedPrefix,
+    systemPrompt,
+    timestamp: Date.now(),
+    ttl: CACHE_TTL,
+  };
+
+  contextCache.set(cacheKey, cachedContext);
+
+  // Cleanup old entries if cache exceeds max size
+  if (contextCache.size > MAX_CACHE_SIZE) {
+    const oldestKey = Array.from(contextCache.entries())
+      .sort((a, b) => a[1].timestamp - b[1].timestamp)[0][0];
+    contextCache.delete(oldestKey);
+  }
+}
+
+/**
+ * Retrieve cached context if available and not expired
+ */
+export function getCachedContext(
+  conversationId: string,
+  messageCount: number
+): CachedContext | null {
+  const cacheKey = generateCacheKey(conversationId, messageCount);
+  const cached = contextCache.get(cacheKey);
+
+  if (!cached) return null;
+
+  // Check if cache has expired
+  if (Date.now() - cached.timestamp > cached.ttl) {
+    contextCache.delete(cacheKey);
+    return null;
+  }
+
+  return cached;
+}
+
+/**
+ * Clear cache for a specific conversation
+ */
+export function clearConversationCache(conversationId: string): void {
+  const keysToDelete: string[] = [];
+  for (const [key] of contextCache.entries()) {
+    if (key.startsWith(conversationId)) {
+      keysToDelete.push(key);
+    }
+  }
+  keysToDelete.forEach(key => contextCache.delete(key));
+}

Evidence

The key includes messageCount and is used both for writes and reads, so any change in message length
changes the key and prevents reuse. The deletion logic performs a prefix match on the full key
string, which is unsafe when conversation IDs are not uniquely prefix-free.

lib/utils/context-cache.ts[24-38]
lib/utils/context-cache.ts[67-83]
lib/utils/context-cache.ts[88-96]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The cache design is unlikely to produce hits across conversation turns because the key changes every time message count changes. Cache clearing can also delete entries for other conversations due to `startsWith()` prefix collisions.

## Issue Context
This file is newly introduced and currently appears unused, so fixing now prevents baking in broken behavior when it gets integrated.

## Fix Focus Areas
- lib/utils/context-cache.ts[24-38]
- lib/utils/context-cache.ts[67-83]
- lib/utils/context-cache.ts[88-96]

## Suggested fix
- Make the key stable per conversation + checkpoint, not per exact messageCount. Options:
 - Key by `conversationId` only and store the latest checkpoint inside the value.
 - Or key by `conversationId:${checkpoint}` where `checkpoint` is the cached prefix length (e.g., `Math.floor(messages.length * 0.8)`) and look up the most recent checkpoint <= current messageCount.
- Fix clear logic to match `conversationId` exactly:
 - Use `key.startsWith(conversationId + ':')`, or
 - Split keys on `:` and compare the first segment.
- (Optional) Consider periodic cleanup of expired entries during `getCachedContext()` or via a lightweight sweep to avoid accumulating expired entries until they’re accessed.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools